This disclosure relates generally to conditional-load and conditional-store operations in a data processing system and, more specifically, to performing safe conditional-load and conditional-store operations in conditions when storage access cannot be proven safe in the data processing system.
Conditional operations in the form of LOAD_ON_COND and STORE_ON_COND operations typically provide a significant performance advantage for data-driven branches that are difficult for branch predictors of program code compilers to predict reliably. In some instances, LOAD_ON_COND and STORE_ON_COND operations can provide fairly dramatic improvements to the performance of a program because penalties□associated with mispredicted branches are removed.
For example, using the following code snippet representative of a common code pattern for a LOAD_ON_COND operation of:
x = 0;if (a > 10)## data-driven and poorlypredicted{x = *ptr;}a typical implementation of the code snippet is:
LOAD_IMMRx, 0## x=0COMPARERa, 10## Cond <= (Ra > 10)BRANCHGT, Label## Branch is poorlypredictedLOADRx, 0(Rptr)## Load *ptr into XLabel:The typical implementation can be further transformed into a reduced form of:
LOAD_IMMRx, 0## x=0COMPARERa, 10;□##□LOAD_ON_CONDRx, GT, 0(Rptr)## Load *ptr into X if Ra>10The transformation thereby avoids the branch prediction through predication of the assignment of *ptr to x.
There is however an important limitation to the use of the transformation. The LOAD_ON_COND can only be used safely in situations in which the source of the load is proven to not cause an access violation independently of an outcome of the conditional operation. Implementations of LOAD_ON_COND typically perform the load operation implicitly independent of the respective condition and, accordingly, cause an access violation even when the respective condition for the load is false. For example, in the following implementation:
LOAD_IMMRt, 1COMPARERptr, NULL ## sets condition code□LOAD_ON_CONDRt, NE, 0(Rptr)## Loads value at storagelocation 0(Rptr) into Rtcondition code NEan access violation will occur on systems where page 0 is not readable when Rptr is NULL.
For a Load-on-Condition transformation to work correctly, a compiler must therefore have sufficient contextual information about *ptr to prove that the source of the load will not cause an illegal access exception independently of whether the respective condition for the load is true or false.
In a similar manner a Store-on-Condition can only be used safely in situations in which a location into which a storing operation is performed does not cause an access violation. For example, using the following implementation:
MOVE0(array),H‘0’COMPARERa, 10STORE_ON_CONDRx, GT, 0(array)When the address of the array variable is invalid, an access violation will occur on systems using the example implementation.
Some previous attempted solutions use hardware transaction memory, as a mechanism to detect bad access to the physical memory. In another example of previous attempted solutions, a technique in which speculative elimination of null checks in regions is used. However, the technique is only useful in the presence of a virtual memory subsystem, such as used in an implementation of a Java virtual machine to detect null references. In another previous attempted solution, new hardware logic is utilized to improve branch prediction.